I will give this PR a more thorough review, but my initial reaction is that the relationship between TLB index and (x,y) location is something UMD should hide.

UMD has to know about the TLB windows, there's no way around that. But the application does not. It shouldn't matter what TLB is mapped where as long as UMD/KMD manage these resources effectively.

I will give this PR a more thorough review, but my initial reaction is that the relationship between TLB index and (x,y) location is something UMD should hide.

UMD has to know about the TLB windows, there's no way around that. But the application does not. It shouldn't matter what TLB is mapped where as long as UMD/KMD manage these resources effectively.

I agree, but bear in mind that this is not what this PR is about. This is not a final API, it is just pointing in the right direction, that TLB setup is chip specific. We might end up removing it altogether in the end

• undermines performance and has led to workarounds (get_fast_pcie_static_tlb_write_callable and tt::Writer).

I completely agree. But it is fine for me to have a more flexible API for slower access, and a performant option (such as tt::Writer, or as you suggested TLBWindow, which I ended up suggesting be AbstractIO in the end).

On the other hand I do want to investigate maps that we use a bit. Theoretically, it shouldn't be expensive to use a hash map. It is known to have a bad implementation in stdlib though, there are much better options. I also suspect that just changing everything to map and set would improve perf (they should be more performant for very small containers, which are ours). Hash maps are not slow by design, and I'd very much like to get to the bottom of where the perf issue really is.

Related tenstorrent/tt-metal#13949 got approved, so now merging this PR.